监控项也扯了，触发器也做了，也确实收到告警了，但是你得一直坐屏幕前面盯着啊，你总得休息吧。总得回家吧。那么对应的我触发器触发了我就得做点什么了，比如发报警邮件或者短信等等。运维工程师又不是服务器保安，没必要天天坐在监控机旁边守着。。

通知事件

        定义一个通知介质：

        这个介质可以是邮件，shell脚本，也可以是sms短信，遇到紧急的问题的时候，一个短信往往可能是比一封邮件更有效的办法。

        配置Actions：

        Actions顾名思义，就是动作，行动。Actions由Conditions（条件）和operation（操作）组成。当满足特定的执行条件的时候就会采取对应的操作，这就是action。

        我们现在创建的是trigger的action，对应的还有自动发现的，注册事件的，内部事件的action。

• Name：action的名字
• Default Subject：报警通知的主题，如果你发邮件的话就是邮件主题
• Default Messages：通知内容，如果你发的是邮件的话就是邮件内容。
• Recovery message：这个东西勾上，如果故障恢复了的话也会发送通知
• Recovery subject：恢复主题
• Recovery subject：：恢复信息
• Enabled：应用，生效。

        Condition:

• Type of calculation：条件之间的关系，有AND/OR，AND，OR，与或非这个我就不说了。二者都满足和满足其中一者。
• Condition：条件，A为机器不在维护状态，B为触发器状态为PROBLEM
• New Condition：在这里可以添加更多的条件

        Operations:

        点击编辑：

• steps：1-1就是一次，1-10就是发10次（如果故障不恢复才发10次）。如果是1-0的话就代表没有限制的。这个steps可以是多个的。比如与1-10次发给你，5~10次的时候就开始发给你的主管了，11~15次的时候发送给你的部门经理……这就是之前说到的故障升级。故障持续的时间越长，发送的人也不一样。一旦故障级别不一样，能拍板说话算数的人也就不一样了。
• step duration：每隔多久操作一次。这个支持故障升级，第一次发给运维，多久没解决后，发给运维主管，多久没解决以后发给运维总监，多久后发给所有人，还没解决你就直接GG，这个的实现就是依靠这个步骤。
• 操作类型：发送消息、远程命令
• send only to：通过什么途径发送，和发送给谁。（Email SMS Jabber） 可以添加用户组和用户，发送给用户组和用户。

        改完了要点更新（add），那个不是最下面的蓝色的更新是，蓝色更新上面那个更新。

通知给谁？

        Adminstrator→Media Type设置媒介类型→create media type，进行新的媒体类型的添加。比如添加一个send_sms的媒体类型拥有自定义媒体类型。